Pipeline run for PR dotnet#5952 surfaced two Linux-specific issues with tests this
PR had un-skipped under CoreWCF. Both failures reproduce against the
SelfHostedCoreWcfService on Helix Linux but pass on Windows.

1) Tcp_ClientCredentialTypeCertificateCanonicalNameTests:
   .Certificate_With_CanonicalName_DomainName_Address_EchoString
   .Certificate_With_CanonicalName_Fqdn_Address_EchoString
   On Linux containers Dns.GetHostEntry("127.0.0.1").HostName resolves to
   "localhost" (verified with getent hosts 127.0.0.1). CertificateGenerator
   uses that value as the subject CN for the "DomainName" / "Fqdn" certs
   (CertificateGeneratorLibrary.cs:17-18), so on Linux those certs are
   indistinguishable from the Localhost cert. The tests assert a NEGATIVE
   case ("connect to localhost -> server presents DomainName cert -> identity
   check must fail"), which can never hold when the cert CN is also
   "localhost". This is a pre-existing test-infra limitation unrelated to
   CoreWCF; the tests also fail on Linux against a real WCF service.
   Fix: gate on Is_Windows in addition to Root_Certificate_Installed.

2) ClientBaseTests.DefaultSettings_SetCookieOnServerSide:
   Server-side Kestrel race on certain Linux distros (Fedora.41, Debian.12;
   passes on Ubuntu, AzureLinux, openSUSE on the same Helix run):

       Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[14] communication error.
       System.InvalidOperationException: Writing is not allowed after writer was completed.
          at System.IO.Pipelines.Pipe.GetMemory(Int32 sizeHint)
          at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.DoReceive()

   The second POST on the keep-alive connection occasionally hits a
   CoreWCF/Kestrel pipe-writer race and the client receives a
   "Connection reset by peer". Not addressable client-side.
   Fix: restore [Condition(nameof(Skip_CoreWCFService_FailedTest))] with a
   comment explaining the failure mode.

Other un-skipped tests in the PR (WebSocket_Https_Duplex_Buffered and the
strengthened WSHttpBinding_TransactionFlow_Mandatory_RoundTrips_And_WithoutScope_Throws)
remain unchanged.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…n run

The Certificate_With_CanonicalName_{DomainName,Fqdn}_Address_EchoString tests
assert a NEGATIVE identity check: a client connecting to "localhost" must be
rejected because the server presents a certificate whose CN is a DIFFERENT
name. This only worked on Windows because the cert generator derived the CN
from Dns.GetHostEntry("127.0.0.1").HostName, which returns the machine name on
Windows but "localhost" on Linux/macOS. With CN="localhost" the certs were
indistinguishable from the localhost cert, so the negative assertion could
never hold and the tests failed on the CoreWCF Linux CI legs (hence they were
previously gated to Windows only).

Introduce a runtime switch in CertificateGeneratorLibrary:
  * Windows  -> Dns.GetHostEntry("127.0.0.1").HostName  (unchanged)
  * non-Win  -> Dns.GetHostEntry(Environment.MachineName).HostName, with a
                fallback to Environment.MachineName if the name is unresolvable
                or resolves to "localhost".

The new canonical name is used ONLY for the two SubjectCanonicalName certs.
The CRL service URI, the main machine certificate, and the expired/revoked/
alt-name certs continue to use the existing localhost-based s_fqdn/s_hostname
so CRL fetching and general localhost TLS are unaffected.

With this the Is_Windows gate added earlier is removed; the tests run on all
platforms again (still [Issue(3572, OS = OSID.OSX)] for macOS).

Verified locally on WSL Ubuntu-24.04 against the SelfHostedCoreWcfService
(RunWithCoreWCF=true):
  * Certificate_With_CanonicalName_DomainName_Address_EchoString  -> Passed
  * Certificate_With_CanonicalName_Fqdn_Address_EchoString        -> Passed
  * Certificate_With_CanonicalName_Localhost_Address_EchoString   -> Passed
  * Full Security.TransportSecurity suite: 0 failed (13 passed, 53 skipped)
Windows behavior is unchanged (the Windows branch resolves to the identical
Dns.GetHostEntry("127.0.0.1").HostName value used before).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>